還記得容器的主要效益之一嗎？是頻繁且心安的進行改版。剛好改版就是維運端最擔心的事情之一，所以維運人員和容器應該一拍即合？

先來談談改版的理想狀況。開發人員把新的、且已經測試過的容器樣板簽入到容器的版控系統之後，維運人員只要能知道容器要用哪個樣板，以及要啟動容器用的設定檔，把設定檔從版控系統中簽出並調整好後 (理想上各種環境的設定應該要寫在一起) 簽入到版控系統，按下確認要佈署的按鍵之後，剩下的佈署工作就是容器平台要處理的。

再來談談問題排除的理想狀況。理想狀態是是維運人員根本不需要熟悉容器裡應用要如何除錯，如果遇到問題，就把舊容器砍掉，重新開一個全新的容器頂上去。你可能聽過 pets vs. cattle，容器就是實現的手段之一。

聽起來很美好，這就是維運的完美境界啊 (遠望

讓我們回到現實吧，現實是

• 應用架構要特別設計，也就是你也可能聽過的 stateless application，才能像 cattle 一樣可以直接用新的頂替。stateless application 有諸多設計上的限制，能套用的應用也相對較少。
• Stateless application 因為限制多，所以通常顆粒度也不會太大，所以要管理的應用數量會增加，造成維運的管控成本會增加。
• 有些非容器化的外部相依 (比方說資料庫)，若沒有細心的去管理 (減少人為操作以避免不一致)，在各種環境中還是有差異的，所以不能保證在 Test/Staging 測試 OK 的應用就能順利在 Prod 上跑起來。
• 雖然說「重開治百病」，但有些問題不是重開就能解決的，比方說嚴重的 memory leak，這種問題需要在開發測試階段就先補抓到。
• 容器是需要流程搭配的技術，但有些組織流程、人員分工、人員專業、人員習慣都不是一時三刻能調整的。尤其維運是SOP紀律導向，要穩定維運唯有把上面各種因子串連堅固化，這相對來說是很難重新調整的。若沒有有調整權力的主管去推動，以上任何一個因子都可以卡死。
• ...應該還有很多議題是我沒有點到的，在請大家幫忙補充吧。

但從這些現實問題上，我們也可以看出些影子，為什麼容器常常和 DevOps 一起談？因為 容器可以強迫 Dev 考慮一些原本 Ops 應該要考慮的事情，這就是 DevOps 的初衷。所以 Ops 應該要比 Dev 更歡迎容器的啊，只是如前面所說，Ops面臨到更多組織面的阻力。

容器是可以搭配 DevOps 的工具，但是組織面有提供 DevOps 的誘因與激勵嗎？ Culture？

技術在組織中發揮的障礙還是在人啊，尤其是像容器這種會改變流程運作的技術。